There are a great many different kinds of devices that can connect to Wide Area Networks, for example (but not limited to) the World Wide Web, or Internet. Different devices have different capabilities for operating on data they receive, for example to present it to a user. Common ways of presenting information to a user include on a display screen or using audio microphones, or both. Different devices need to operate upon data to be presented to a user with the data presented in different formats or protocols. For example, the screen size, number of pixels, audio frequency output range, colour capability, data reading rate, etc. may differ between devices. Also devices connected to a network may have different input, output, hardware, software, network and browser capabilities. Thus the creator of a network-accessible document, or work, has difficulty in designing one single work suitable for presentation to a user on all possible devices that may be connected to the network. As the number of devices accessing a network increases the problem of enabling a work to be presented to users on the increasing number of different types of devices gets worse.
A solution is to create a separate work, with device specific formatting, for each possible kind of device that can access the network, and have a data content server identify the requesting device that is requesting a work, and serve out the requested work in the format applicable to the requesting device. This has been done at present, but as new devices become available the work involved grows. It is not only end user devices such as mobile telephones, personal digital assistants (PDAs), PCs, laptops, etc. that require format adjustment of the data work, but also intermediaries in the telecommunication chain may also impose a need for specific format requirements (e.g. routers, or relay computers).
A desire has emerged to make network accessible works, e.g. web pages, easier to serve out and design to at least some degree: to have works be at least partially device independent by having works be accessible by a range of devices without having to store the whole work and serve out the whole work in a separate format for each kind of device with different capabilities.
There are at least three ways to achieve a degree of device independence for data works: Intermediate Adaptation; Client-Side Adaptation; and Server-Side Adaptation.
In order to avoid changing the server that provides a data work, or changing the data work itself, or the client device that receives or consumes it, an intermediary, or intermediaries, in the content delivery chain of communication between the server and the client can adapt the data work they receive from the server to make it more suitable for the client before transmitting it on. Transcoding proxies can, for example, transform the data work, for example, transforming image formats, or subsets of mark-up language. A practical example of this is to enable data-enabled telephones access to web sites by either omitting a server's full-resolution colour images or transcoding them into low resolution, or monochrome versions, depending upon the client telephone's capabilities.
Client-Side adaptation involves, typically, having a web browser (as an example of a network-accessing agent) adjust the presentation of data works on its client device. Client-Side adaptation code works in an environment where the capabilities of the client device are known, and modifies the received data (e.g. from a server or other data work supplying device) to allow the client device to use it. An example is modification of a screen image to suit the screen size of a device. Sometimes this may be achieved by omitting parts of the web page/data work that has been received. This is wasteful of delivery bandwidth.
A further option is Server-Side adaptation where the data work server is adapted to change what is served out dependent upon a knowledge of the capabilities of the requesting client device. Server-Side adaptation retains to the server control of what is served out. The data works provider may be able to provide multiple versions of the work to be served out, suitable for different categories of delivery context, or may have a basic core work and apply modifications to that work based upon different categories of delivering context.
Factors that affect the delivery context include the data work delivery devices capabilities, the network characteristics, (including if applicable the characteristics of networked devices that form part of a data work delivery pathway in the network), the client device capabilities, and if applicable the condition of user-set settings available on the client device: things which affect the successful receipt by a client device of data representative of a selected data work. The delivery context includes one or more, or all, of the foregoing (which is not an exhaustive list).
Delivery context aware supply devices, such as data work supply servers, can evaluate at least some delivery context information applicable to a request for a work from a client device and can tailor the data they supply depending upon the evaluated delivery context. Delivery context aware devices may be able to evaluate a plurality of, or all of, information relating to: data work (or resource) provider device capabilities; network characteristics; characteristics of devices that form part of a delivery pathway in the network; client device capabilities; the condition of configurable settings on the client device or other devices in the pathway from work (or resource) server to client device.
There are currently at least two standards used by client devices to describe their capabilities to data work supply devices, such as web servers: Composite Capabilities/Preferences Profile (CC/PP) (created by the world-wide web consortium), and User Agent Profile (UAProf) (created by the WAP forum). CC/PP and UAProf enable a client device to specify its capabilities, and enable intermediary devices to specify their capabilities. These capabilities, along with the capabilities of the network service between the client device and the work supplier device, comprising the delivery context, can be used by delivery context aware resource supplier devices to perform content specialisation (i.e. adapt, select, or generate content based on the delivery context information), as discussed.
Using the Internet as an example, most devices on the Internet use HTTP, a stateless protocol, to retrieve content from data work supplier servers. Both CC/PP and UAProf capable devices have to convey their delivery context to the server as part of every HTTP request. If the entire delivery context information, known as the “profile”, was within each request then these requests from the client devices would be network inefficient; a lot of data would be communicated with each request. CC/PP and UAProf break up the profile into two sections: the reference profile, representing a standard profile for that kind of client device, and a list of perturbations, or overrides, specific to the specific instances of the kind of device, specific to the actual client device making the request. These are known as the “profile-difference” (or profile-diff). The reference profile is associated with a unique web location, the URL (Uniform Resource Locator) that is the network address for an actual instance of the profile on a networked web server known as the profile repository. The profile repository may be supported/controlled by an organisation associated with the client devices (e.g. the manufacturer of the devices), or by an organisation associated with the network provider (e.g. the telecommunications network owner), or by another organisation (e.g. the ISP).
When a delivery context aware work supply device, such as a server, receives a request for a data work (e.g. a HTTP request) from a client device which has conveyed with it delivery context information it currently retrieves the reference profile and merges it with the profile-diff in a profile resolution operation to establish the profile of the target client device.
Servers are known to cache reference profiles in a local memory (local to the servers meaning that the memory is accessible without incurring a significant telecommunications delay) to reduce the time, and/or bandwidth, needed for profile resolution. Retrieving a reference profile from a local cache is more efficient than retrieving it repeatedly from a remote profile repository over the Internet.
However, the above reference profile/profile-diff resolution process can have difficulties. For example, if a profile repository is unreachable and a profile that is needed is not already in the more local cache of a data content, or work server, the server may not be able to create a profile for the requesting client device and may therefore not be able to serve out a requested work to the requesting client device, either not at all, or not in a format that is known to be acceptable to the client device.
If a server does have a cached reference profile, that profile might be out of date: sometimes changes to a reference profile are necessary (e.g. to correct errors, or to allow for newly available intermediary devices etc.).
It is also likely that servers will encounter client devices which do not implement the appropriate standards correctly, so that the server cannot return useful content.
A further issue is that different kinds of device, for example provided by different manufacturers, use different capability vocabularies. This means that servers must know about the different vocabularies in advance, if they are to serve out resources properly. Alternatively, it is known to have a server retrieve information about a vocabulary from a vocabulary repository. If the vocabulary repository is unavailable the server may be unable to serve out requested resources.
Thus a network may have a plurality of data work suppliers, such as servers, that are context delivery aware, a plurality of data work suppliers that are not context delivery aware, and a plurality of client devices. The performance of the context delivery aware data work supplier devices depends upon how they are set up to behave, and the reliability of links to reference profile repositories and vocabulary repositories.